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REMARKS 

Claims 1, 5 and 12 are currently pending in the application. Claim 1 has been allowed. 
Claim 12 was withdrawn from consideration and has hereby been reinstated in an amended form. 
No new matter has been added. The Examiner has rejected claim 5. In light of the following 
remarks. Applicant respectfully submits that all pending claims are patentably distinct and in 
condition for allowance. Reconsideration and allowance of claims 1, 5 and 12 are respectfully 
requested. 

A restriction was made to the claims under 35 U.S.C. § 121, wherein Group I included 
Claims 1 and 5 and Group II included Claim 12, During a telephone conversation between the 
Examiner and Brian Michaelis on November 21, 2006, Group 1 was elected. Affirmation of this 
election is hereby being made by Applicant. 

35 U.S.C. S 102fe) 

Claim 5 was rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent No. 
6,065,058 Hailpem et al. (hereinafter referred to as "Hailpem"). Applicant respectfiilly traverses 
this rejection. 

Claim 5 recites a method of distributing information to a set of servers connected via a 
communication network. The method includes the steps of obtaining a list of servers, 
prioritizing the list according to parameters associated with each server, and issuing instructions 
to each server in the listed order. The instructions include the identification of a source for 
obtaining the information and an identification of the next server on the list. In addition, the 
method includes distributing the information according to the instructions and notifying each 
server when the prioritized list is exhausted. The steps of issuing instructions and distributing 
the information include obtaining an address of a first server address on the list, sending a 
notification message with the address of a second server having an information file to distribute 
and requesting a copy of the information from the second server. The copy of the information is 
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sent to each server on the list in an order determined according to the order of the Ust and the 
transmission time in the network. 

Hailpem teaches a push-based filtering of objects in a client-server hierarchy based on 
usage information. The method includes objects that can be staged at the server to provide fast 
access when the filtered object is later requested. An object may include a content hierarchy 
such as a title, a summary and the full content. The filtering process can factor in which next 
level nodes will receive the push and also the content level each node will receive. 

The Examiner referenced portions of Hailpem and incorrectly asserted, among other 
things, that Hailpem essentially discloses applicants' invenfion. 

Contrary to the Examiner's suggestions, the first referenced portion of Hailpem merely 
teaches that an object is either pushed down to the lower level or it will try to obtain the object 
from its next higher level proxy, as in column 5, lines 35-44. Hailpem fails to teach, suggest or 
disclose obtaining a list of servers desiring to participate in a distribution, as particularly claimed 
in Claim 5. 

The second referenced portion of Hailpem further teaches that the server passes 
information on the object and its staging decision along with the object to the next level and two 
different categories used, the usage category and the preference category. The usage category 
conveys the frequency of the object being referenced and the preference category conveys the 
profile information, as taught in col. 5, lines 52-57 and col. 7, lines 26-36. Hailpem fails to 
teach, suggest or disclose prioritizing the list according to parameters associated with each 
server, as particularly claimed in Claim 5. 

The third referenced portion of Hailpem teaches a staging label used to communicate and 
share information as the object passes through the hierarchy. The staging value of an object is 
denoted by a binary value. In addition, the proxy checks if the request received from the lower 
level contains a user label, as taught in col. 7, lines 36-60 and col. 9, lines 1-21. Hailpem fails to 
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teach, suggest or disclose issuing instructions to each server in the listed order , including the 
identification of a source for obtaining information, as particularly claimed in Claim 5. 

The fourth referenced portion of Hailpem merely teaches that if a whole object is pushed 
down to the next level, then the push object filtering routine is invoked. And, if only a summary 
information is pushed down from the higher level, the push summary filtering routine is invoked 
to determine whether to push the summary to a lower level, as taught in col. 9, lines 22-40. 
Hailpem fails to teach, suggest or disclose distributing the information according to the 
instructions, as particularly claimed in Claim 5. 

The fifth referenced portion of Hailpem teaches setting a staging value of an object and 
denoting it by "CV". A binary value representation is used to determine the CV value. The 
value is determined by including for an n-th level proxy, the CV value includes n bits and the k- 
th bit has a value of one if the (n-k) level proxy has staged the object when it passes the object 
down the hierarchy, as taught in col. 7, lines 48-60. Nowhere in Hailpem does it teach, suggest 
or disclose notifying each server when the prioritized list is exhausted , as particularly claimed in 
Claim 5. 

Another referenced portion of Hailpem teaches the overall architecture of the hierarchy 
of the proxy servers. They are connected through a hierarchy of proxy servers to the Intemet, 
and the servers pass information on the push object and its staging decision along with the 
object, as taught in col. 5, lines 8-27 and 45-57. Nowhere in Hailpem does it teach, suggest or 
disclose obtaining an address of a first server address on said list, or sending a notification 
message containing the address of a second server, or requesting a copy of the information from 
the second server, as particularly claimed in Claim 5. 

Therefore, for the aforementioned reasons, Claim 5 is patentable over Hailpern. 
Applicant respectfully requests that this rejection be withdrawn. 
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Applicants have amended claim 12 herewith to present it as a further limitation of claim 
5. Accordingly, for at least the foregoing reasons claim 12 as dependent from claim 5 is 
patentable over the prior art. 

Double Patenting 

Claims 1 and 5 are rejected under the judicially created doctrine of obviousness-type 
double patenting as being unpatentable over Claims 1 and 3 of U.S. Patent No. 6,748,447. 
Applicant have hereby attached a terminal disclaimer and therefore request that this rejection be 
withdravm. 
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CONCLUSION 

In view of the remarks set forth above, it is respectfully submitted that this application is 
in condition for allowance. Accordingly, allowance is requested. 

Authorization is hereby given to charge deposit account 50-0369 in connection with any 
fees or extension of time or any other fee that may be necessary to permit entry of this response. 
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